-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
gh-126105: Fix crash in ast module, when ._fields is deleted
#126115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering why we have:
if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) < 0) {This could be because some AST nodes do not have a _fields attribute but then, why don't we simply change it to an eager PyObject_GetAttr?
Misc/NEWS.d/next/Library/2024-10-29-11-45-44.gh-issue-126105.cOL-R6.rst
Outdated
Show resolved
Hide resolved
32f5eed to
980aa20
Compare
|
Docs give me more confidence: https://docs.python.org/3/library/ast.html#ast.AST._fields
|
|
I don't think that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
| Py_ssize_t i, numfields = 0; | ||
| int res = -1; | ||
| PyObject *key, *value, *fields, *attributes = NULL, *remaining_fields = NULL; | ||
| if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) < 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A simpler fix would have been this, right?
if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) <= 0) {
However, your fix is better.
pythonGH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
|
Sorry, @sobolevn and @Eclips4, I could not cleanly backport this to |
|
GH-126130 is a backport of this pull request to the 3.13 branch. |
|
I'll take care of backport to 3.12. |
… deleted (pythonGH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
|
GH-126132 is a backport of this pull request to the 3.12 branch. |
…ed (GH-126115) (#126130) gh-126105: Fix crash in `ast` module, when `._fields` is deleted (GH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
|
@Eclips4 thank you for your help! |
#126132) [3.12] gh-126105: Fix crash in `ast` module, when `._fields` is deleted (GH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
python#126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute).
python#126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute).
This PR changes the logic a bit, but it looks like a correct thing to me.
Previously we were handling
NULLoffieldscase forremaining_fieldscpython/Python/Python-ast.c
Lines 5089 to 5098 in 9b14083
But, we didn't really handle the
fieldsitself.Further calls assume that
fieldscannot beNULL.The other way of fixing this is to add a default for
fieldslike:In this case
ast.AST(arg=1)with no_fieldswill produce:It does not seem correct to me, because
_fieldsis a part of our API. SinceASTobjects are mostly internal, there are no real cases of missing_fields.